I remember we had an internal discussion about this and we came to the conclusion instantiating a single Player object for all the callbacks registered for both listeners was in general, not only convenient, but also much better than all of them instantiating their own. Take for example, there is 50 callbacks registered for OnPlayerRunCommand and 50 for OnButtonStateChanged. Instantiating a single Player object for 100 callbacks, even if only 50 of them will use it, still means you globally saved 49 instantiations because only one was instantiated for these 50 callbacks that would otherwise instantiate their own. Without mentioning that changing that now would means breaking all existing codes that currently uses these two listeners as they would all need to be updated to handle the passed argument differently. Thanks for the pull request, but with all that said I'm personally strongly against this proposal. If you wish to use the index, then you should retrieve it from the passed Player. Which to be fair, is very fast because the index is cached in the Entity instance.

I fully agree with @jordanbriere. It's convenient and changing it would break existing code, which we try to avoid since quite some time. A better idea might be to override __new__ and access an internal player dictionary. Then, people don't have to use it anymore on their own and all occurences of the Player class (and might Entity, Weapon, etc. as well) would be speed up immediately.

Anyways, thanks for the PR. I really appreciate that!